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1.0  General 

JMedSAF  provides  medical  facility,  patient,  patient  treatment  and  patient  evacuation  simulation.  The 
patient  conditions  (PC),  treatment,  and  evacuation  parameters  are  derived  from  the  Deployable  Medical 
Systems  (DEPMEDS)  data  as  defined  by  the  Defense  Medical  Standardization  Board.  To  support  the 
Cobra  Gold  Command  Post  Exercises  (CPX),  additional  patient  conditions  were  created  which  represent 
milder  forms  of  the  DEPMEDS  conditions  and  disease/non-battle  injury  distribution  data  was  modified  to 
provide  a  theater  specific  alternative  distribution  more  in  line  with  Master  Scenario  Event  List  (MSEL) 
objectives. 

JMedSAF  supported  the  CPX  by  simulating  the  planned  medical  facilities  and  their  treatment  of  sick  call 
and  battle  injury  patients  over  a  fifteen  day  period.  In  addition,  specific  injections  of  patients  in  support  of 
medical  MSEL  events  were  conducted.  JMedSAF  output  facility  and  patient  reports  to  the  Joint  Medical 
Workstation  (JMEWS)  II  system  which  provides  a  theater  database  for  the  Theater  Medical  Information 
Program  (TMIP).  The  JMEWS  II  database  provided  database  access  to  the  MSE  program  which  provided 
the  common  operating  picture  (COP)  to  the  training  audience,  the  CPX  Coalition  Joint  Task  Force  (CJTF) 
surgeon  and  staff 

The  Coalition  Exercise  Control  Group  (CECG)  for  Cobra  Gold  provided  the  CPX  scenario  environment  via 
the  Joint  Tactical  Logistics  System  (JTLS)  simulation  and  response  cell  personnel.  The  CECG  for  CG06 
was  split  between  “in  country”  operations  at  Sattihip,  Thailand,  and  Camp  Smith,  Hawaii.  The  Camp 
Smith  component  consisted  of  a  JTLS  database  server  and  the  medical  cell  systems  (JMedSAF,  JMEWS  II, 
and  MSE).  Exercise  communication  was  provided  via  a  closed  Coalition  Wide  Area  Network  (COWAN) 
established  in  Thailand  with  a  reach  back  capability  to  Camp  Smith. 

The  medical  simulation  cell  configuration  is  shown  in  the  figure  below.  Note  that  the  configuration  is 
simplified  and  represents  the  “local”  Camp  Smith  COWAN  only.  The  circuits,  primary  and  backup,  to 
Thailand  are  assumed  in  the  diagram  box  labeled  “Exercise  COWAN”. 


Cobra  Gold  2006  Configuration  Diagram 


JMedSAF 


Figure  1-  Simplified  CG06  Configuration 
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2.0  Pre-Exercise  Activity 

2.1  Exercise  Preparation 

Exercise  preparation  consisted  of  three  primary  activities:  data  collection,  scenario  generation,  and  testing. 

Data  Collection: 

There  are  three  primary  sources  of  information  that  provide  the  scenario  entities  and  execution 
expectations.  These  are  exercise  planning  documents  (including  OPORD  and  briefing  materials),  the 
Time-Phased  Force  and  Deployment  Data  (TPFDD)  and  the  Master  Scenario  Event  List  (MSEL). 

The  primary  information  needed  is: 

•  Medical  facility  names,  types,  and  locations 

•  Unit  names  and  Population  At  Risk  (PAR) 

•  Unit  operating  areas  (which  MTF  will  provide  medical  services) 

•  Exercise  requirements  for  specific  disease  injections 

The  overall  CPX  story  line  and  initial  medical  facility  information  was  provided  by  Mr.  Sashin  and  was 
based  on  planning  conferences  and  his  estimate  of  medical  requirements. 

The  initial  list  of  medical  facility  types  was  further  enhanced  by  an  MTF  capabilities  assessment  from 
service  representatives  coordinated  by  Mr.  Merrick  Flarrison  (PACOM).  This  information  was  used  to 
refine  the  facility  templates  used  in  JMedSAF. 

Mr.  Sashin  also  provided  the  initial  set  of  medical  related  MSEL  events.  These  were  reviewed  for 
JMedSAF  support  requirements  or  issues. 

In  place  of  TPFDD  data,  the  tactical  simulation  JTLS  database  was  used  to  extract  unit  identification, 
population,  and  location  data.  The  JMedSAF  team  extracted  this  information  during  the  Cobra  Gold  JTLS 
Database  Test  conducted  27  to  30  March  2006.  During  the  JTLS  database  test  period,  MSAT  coordination 
meetings  were  also  conducted  to  establish  scheduling  and  MSEL  injections. 

The  March  database  test  period  provided  the  following  information: 

•  Lists  of  JTLS  unit  names  and  locations  were  produced.  (US,  Thailand,  and  Singapore) 

•  A  revised  MSEL  list. 

•  A  revised  medical  laydown 

Scenario  Generation: 

A  JMedSAF  scenario  is  represented  by  three  sets  of  files:  a  single  loadable  scenario  file  consisting  of  MTF 
entities,  a  file  defining  the  theater  level  sick  call  level  and  locations,  and  a  set  of  clean  facility  “saved”  files 
which  defines  modifications  to  staffing  or  other  parameters  for  each  facility. 

Based  on  the  data  obtained  during  the  MSAT  coordination  meetings,  the  core  scenario  file  was  constructed 
and,  after  modifications  were  made,  the  “saved”  files  were  created.  The  creation  of  the  theater  sick  call  file 
required  considerable  additional  effort. 

The  nature  of  JTLS  required  use  of  three  different  systems  to  produce  a  list  of  exercise  units  for  each 
national  participant.  In  addition,  the  Cobra  Gold  2006  exercise  was  set  in  a  fictional  continent  which  was 
basically  the  United  States  west  coast  dropped  into  the  middle  of  the  Pacific  Ocean.  This  fictional 
continent  was  named  “Pacifica”.  JMedSAF  does  not  have  a  terrain  database  for  Pacifica  and  therefore  used 
the  actual  United  States  west  coast  terrain.  In  order  to  create  the  master  theater  Disease  Non-Battle  Injury 
(DNBI)  file,  the  JTLS  position  for  each  unit  (a  list  of  813  culled  from  the  original  1150)  had  to  be 
translated  and  plotted  on  the  US  west  terrain  so  that  the  appropriate  sick  call  MTF  could  be  identified. 

The  JTLS  output  does  not  include  the  actual  manning  level  of  these  units  but  merely  identifies  them  as 
organization  entities  (Division,  Brigade,  Battalion,  etc.).  In  addition,  the  service  (USA,  USMC,  RTA, 
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RTMC)  is  not  included.  The  units  are  merely  identified  by  country  (US,  Thailand,  or  Singapore). 
Population  numbers  for  each  unit  were  derived  by  assigning  the  normal  level  for  that  echelon.  Service 
identification  was  derived  by  backtracking  the  listed  “HQ”  to  the  CARFOR,  CMARFOR,  or  CAFFOR 
organizational  structure. 

In  addition  to  the  tactical  scenario  development,  a  separate  scenario  was  created  to  simulate  one  of  the  CPX 
refugee  camps.  The  scenario  information  was  derived  from  the  camp  descriptions  document.  The  same  set 
of  scenario  and  supporting  files  were  created  and  additional  disease  trend  files  (DDJ)  were  created  to 
represent  the  camp  diseases  prevalent  outside  the  normal  frequency  distribution. 

Testing: 

During  the  March  and  April  2006  time  frame,  software  changes  were  made  to  expand  the  JMEWS  II 
interface  and  improve  JMedSAF  processing.  As  these  changes  were  implemented,  unit  and  system  level 
testing  was  conducted. 

As  the  scenario  generation  process  came  together,  practical  testing  of  the  scenario  was  conducted.  The 
objective  of  this  testing  was  to  verify  MTF  process  of  all  patient  types,  patient  flow  within  the  medical 
laydown,  and  to  identify  any  issues  resulting  from  MTF  locations  and  limitations.  In  addition,  the  disease 
and  injury  frequency  distribution  tables  were  tested  and  modified  to  provide  a  CG06  specific  disease 
distribution.  This  alternate  theater  DNBI  table  was  tailored  to  support  a  general  increase  in  respiratory 
conditions  and  other  MSEL  related  conditions. 

From  11  to  13  April,  an  end-to-end  test  was  conducted  at  the  Fleet  METOC  Advanced  Concepts 
Laboratory  (FMACL),  Coronado,  CA.  This  test  was  to  verify  the  JMedSAF  to  JMEWS  II  to  MSB 
interface  configuration.  The  design  was  to  primarily  test  the  data  transfer  rather  than  content.  As  the  test 
progressed,  some  issues  concerning  JMedSAF  input  were  uncovered  and  these  were  addressed  either  in 
JMEWS  II  parsing  or  in  JMedSAF  software  changes.  After  the  test  was  completed  on  13  April  2006,  a 
JMEWS  II  system  was  left  at  the  FMACL  and  the  JMedSAF  team  provided  additional  support  to  the  MSB 
developers  over  the  next  two  weeks. 


2.2  Security  Preparations 

Connection  to  the  exercise  COWAN  required  approval  from  PACOM.  Note  that  (see  figure  1  above) 
JMedSAF  did  not  physically  connect  to  the  COWAN,  but  was  connected  to  the  JMEWS  II  server  which 
did  have  a  COWAN  connection.  As  part  of  the  “medical  systems”  configuration,  JMedSAF  was  required 
to  complete  network  security  documentation.  Documentation  consisted  of  the  Security  Profile  Alteration 
Request  (SPAR),  a  systems  description,  and  results  of  the  Security  Readiness  Review  (SRR)  of  the  Security 
Technical  Implementation  Guidelines  (STIG). 

Mr.  Granger,  Akimeka  EEC,  was  tasked  with  creating  the  MSAT  systems  package.  The  SPAR  and 
systems  description  was  delivered  to  Mr.  Granger  16  March  2006. 

In  preparation  for  the  STIG  review,  all  JMedSAF  systems  were  rebuilt  from  scratch  use  the  Fedora  Core  3 
Linux  operating  system.  The  systems  were  locked  down  within  the  limits  of  Linux  and  the  required 
JMedSAF  environment.  After  the  rebuild  and  JMedSAF  software  installation,  the  STIG  SSR  was  run  on 
each  of  the  five  systems.  Additional  security  modifications  to  the  system  were  made  in  response  to  the 
SSR  results  and  the  SSR  was  repeated.  The  output  for  each  system  was  reviewed  and  compiled  into  one 
SRR  form  for  delivery  to  Mr.  Granger.  The  SRR  results  were  delivered  19  April  2006. 


2.3  Documentation 

The  JMedSAF  User  Guide  was  updated  to  reflect  the  JMEWS  II  interface  and  other  modifications  made  to 
date.  The  updated  manual  was  delivered  7  April  2006. 
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3.0  Exercise  Preload  Period 

Upon  arrival  on  the  afternoon  of  8  May  2006, 1  proceeded  to  Camp  Smith  to  set  up  for  the  exercise.  The 
JMEWS  II  and  MSE  systems  had  been  staged  early  in  the  morning  and  were  ready  for  operations.  After 
setting  up  the  JMedSAF  systems,  the  scenario  was  initialized  and  the  connectivity  between  the  three 
systems  was  tested.  The  exercise  COWAN  was  not  available  at  this  time  and  therefore  the  connectivity  to 
Thailand  could  not  be  tested.  It  was  noted  that  the  JMedSAF  interface  program,  resident  on  the  JMEWS  II 
server,  was  not  responding  to  multiple  JMedSAF  backend  systems  input.  It  appeared  that  the  simultaneous 
input  from  the  four  systems  was  not  being  accepted  and  the  JMedSAF  systems  were  timing  out  the 
interface  and  discarding  messages.  This  configuration  had  received  only  limited  testing  in  the  SPAWAR 
laboratory  with  no  apparent  errors.  The  laboratory  configuration,  however,  was  conducted  with  a  JMEWS 
running  on  Windows  XP  standard  PC  and  the  Camp  Smith  system  was  a  server  computer  running  Window 
Server  2003.  JMedSAF  was  reconfigured  to  run  the  facilities  on  a  pocket  system,  which  would  limit  output 
to  one  system.  In  addition,  backend  systems  were  initialized  after  loading  the  scenario  to  handle 
evacuation  vehicles  and  troop  entities  needed  for  wounded  in  action  (WIA)  injections. 

A  preload  of  the  facility  and  patient  database  was  started  on  9  May  2006.  The  preload  period  ran  though 
through  the  16*  of  May  when  the  CPX  officially  started.  This  provided  seven  days  of  history  for  the  CJTF 
surgeon  to  use  at  the  start  of  the  exercise. 

During  the  preload  period,  it  was  discovered  that  JMedSAF  would  experience  a  segmentation  fault  when 
the  every  six  hour  set  of  MEDSITREP  reports  were  generated  with  patients  occupying  an  intensive  care 
unit  (ICU)  bed.  To  provide  the  means  to  correct  this  problem  and  any  future  issues,  one  of  the  backend 
systems  was  taken  offline  and  was  reconfigured  to  allow  recompilation  capabilities.  Mike  Healy,  in  San 
Diego,  provided  the  code  change  to  correct  the  error  and  the  software  was  recompiled  and  distributed  to  the 
exercise  systems. 

Additional  issues  with  JMedSAF  message  output  to  JMEWS  II  were  identified  during  the  preload  period. 
These  were: 

•  JMedSAF  maps  patient  treatment  requirements  against  one  set  of  doctor/nurse  position  titles  with 
no  service  specific  breakdown.  JMedSAF  output  facility  XML  messages  with  the  text  of  this  list 
rather  than  occupation  codes  unique  to  each  service.  This  caused  JMEWS  II  to  indicate  erroneous 
staff  levels  for  all  non-US  Army  facilities.  This  issue  was  addressed  in  JMEWS  II  (Matt  Rauls) 
by  changing  input  parsing  of  JMedSAF  messages  to  accept  JMedSAF  categories  and  provide  more 
accurate  staff  levels. 

•  JMedSAF  has  “hard  coded”  the  theater  command  as  “PACOM”.  This  caused  some  concern  at  the 
CJTF  because  the  Thailand  and  Singapore  medical  facilities  appeared  to  be  commanded  by 
PACOM.  This  issue  was  not  addressed  and  the  CJTF  staff  was  made  aware  of  the  issues  and 
basically  ignored  this  display  information. 

•  JMedSAF  had  preset  supplies  stock  levels  for  a  selected  set  of  supplies.  The  MSE  and  JMEWS 
display  of  this  information  indicated  a  “red”  (zero)  status  for  these  items  as  JMedSAF  messages 
did  not  set  the  “on  hand”  value  as  well  as  the  “stock  level”  value.  This  problem  was  fixed  in 
JMedSAF  by  the  start  of  the  exercise  (16  May  2006). 

Mr.  Mike  Healy  arrived  on  15  May  2006  and  immediately  joined  the  team  at  Camp  Smith.  During  the 
exercise,  Mike  investigated  JMedSAF  issues  and  errors  as  they  were  discovered  and,  if  possible,  provided 
corrected/improved  software. 


4.0  Exercise  Period 

The  CPX  started  on  16  May  2006  and  ran  continuously  until  23  May  2006  (Thailand  dates  were  17  May  to 
24  May  2006).  Medical  simulation  cell  staffing  was  provided  for  the  “Thailand”  day  shift  period  only. 

The  shift  started  at  approximately  13:00  Hawaii  time  and  ended  at  approximately  01:00  Hawaii  time.  The 
following  is  the  general  daily  schedule  (Hawaii  times  only): 


Time(s) 


Activity 
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Time(s) 

Activity 

13:00 

Review  system  status,  recalculate  “bed  counts”  and  modify  MEDSITREPS,  prep  for  morning 
synchronization  phone  conference. 

14:00 

Morning  synchronization  conference  with  in-country  personnel,  MSEL  discussion, 
problem/issue  discussion 

13:00- 

23:59 

Monitor  patient  activity  and  simulation  performance,  inject  patients  needed  for  MSEL 
support. 

16:00- 

23:00 

WIA  patient  identification  and  injection  (Mr.  Sashin  called  from  Sattihip  Thailand  with  the 
WIA  numbers  when  they  became  available). 

18:00 

Provide  Annex  Q  type  data  for  input  to  CJTF  (C.  Riley  forwarded  via  email  to  CDR 
Moszkowwicz). 

00:01 

Evening  synchronization  phone  conference,  MSEL  discussion,  problem  issue  discussion. 

4. 1  Major  Issues  Affecting  JMedSAF  Operations 

JTLS  Coordination 

The  JTLS  tactical  simulation  had  no  direct  connectivity  to  the  medical  simulation.  The  medical  simulation 
cell  at  Camp  Smith  was  to  have  access  to  a  JTLS  console  for  coordination  purposes.  This  was  to  allow 
identifying  and  locating  units  for  medical  MSEL  purposes  and  to  allow  report  generation  of  wounded  in 
action  (WlA)  activity.  The  PACOM  staff  supporting  the  Camp  Smith  component  provided  staff  coverage 
during  the  Thailand  night  shift  period  only  and  a  console  was  not  initially  available  for  medical  cell  use. 

A  JTLS  console  was  finally  provided  but  was  of  limited  value.  This  was  due  to  the  inability  to  derive 
service/unit  WIA  report  numbers  from  the  JTLS  interface.  Information  of  some  sort  was  available  at  the 
individual  unit  level,  but  WIA  values  were  listed  in  “short  tons”  and  I  did  not  know  how  many  people  were 
in  a  short  ton.  In  addition,  connectivity  problems  between  Hawaii  and  Thailand  were  overcome  at  the 
CECG  by  shifting  operations  to  the  “in-county”  JTLS  server.  The  local  console  provided  was  either  out  of 
synchronization  with  the  in-country  server  running  the  game  or  plagued  by  the  connectivity  issues. 

The  JMedSAF  WIA  injections  were  dependent  upon  phone  or  email  contact  with  Mr.  Sashin  at  the  CECG 
in  Sattihip,  Thailand. 


JMedSAF  Bed  Count  Underreporting 

A  known  problem  with  JMedSAF  processing  is  the  current  accounting  of  patients  in  a  “waiting  evacuation” 
status.  The  current  processing  does  not  allocate  a  “bed  in  use”  for  these  patients  and  therefore  a  facility 
report  of  status  will  not  show  the  appropriate  bed  count.  While  appropriate  software  modifications  have 
been  investigated  and  outlined  to  correct  this  issue,  funding  has  not  been  allocated  to  effect  these  changes. 

Under  normal  operations,  JMedSAF  automates  the  Medical  Regulating  function  and  automatically  provides 
theater  wide  evacuation  management  based  on  patient  condition  needs  and  facilities  capabilities.  The 
automated  regulating  function  will  somewhat  mitigate  the  underreporting  problem  by  shortening  the  time 
period  during  which  the  bed  counts  are  inaccurate  by  moving  patients  in  a  timely  manner.  If  there  are  no 
mass  casualty  situations  and  sufficient  evacuation  assets  available,  the  MEDSITREP  (every  six  hour 
schedule  for  CG06)  should  contain  data  close  to  the  expected  bed  count.  The  exception  may  be  the  medical 
facility  closest  to  an  out  of  theater  staging  facility  where  patients  will  be  held  until  the  out  of  theater 
transport  is  scheduled. 

There  were  many  MSEL  events  that  required  the  CJTF  Surgeon  to  investigate  or  take  on  the  medical 
regulating  function.  To  support  these  events,  JMedSAF  has  to  “shutdown”  the  automated  regulating 
function.  This  is  due  to  the  fact  that  JMedSAF  does  not  support  “directed  evacuation”  for  an  individual 
patient  such  as  “send  patient  A  to  facility  X”.  Patient  “A”  will  only  go  to  facility  “X”  if  the  rules  for  the 
patient  condition,  facility  staff,  supplies,  and  distance  come  up  with  facility  “X”  as  the  right  answer.  To 
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prevent  JMedSAF  from  automatically  moving  the  patients  of  MSEL  interest,  all  evacuations  had  to  be 
suspended.  This  caused  a  considerable  backlog  of  patients  “waiting  evacuation”  at  most  of  the  facilities 
and  a  significant  underreporting  of  bed  usage. 

To  provide  more  accurate  input  to  JMEWS  II  and  thus  better  data  available  at  MSE,  the  automated 
processing  of  JMedSAF  MEDSITREP  messages  at  JMEWS  was  turned  off.  This  does  not  prevent  these 
messages  from  going  to  JMEWS,  but  merely  prevents  them  from  updating  the  database.  A  corrected  bed 
count  for  each  facility  with  patients  “waiting  evacuation”  was  constructed  and  the  latest  MEDSITREP  for 
these  facilities  in  the  JMEWS  input  directory  was  manually  edited.  After  the  editing  was  completed,  non- 
essential  messages  were  removed  from  the  directory  and  the  automated  process  was  turned  on  to  process 
the  corrected  MEDSITREP  messages.  After  processing,  the  process  was  then  stopped.  This  manual 
procedure  was  conducted  prior  to  the  “morning”  phone  call  and  once  again  before  the  daily  summary  data 
was  sent  to  the  CJTF. 


4.2  JMedSAF  Issues  Affecting  JMEWS/MSE 


Multiple  “People”  Table  Entries  for  Single  Patient 

The  creation  of  a  new  patient  by  JMedSAF  should  result  in  one  entry  in  the  JMEWS  “people”  table. 
Subsequent  JMedSAF  message  input  for  a  patient  would  then  be  linked  to  the  same  “people”  table  record 
so  that  an  historical  list  of  events  for  a  patient  could  be  displayed.  JMedSAF  errors  caused  the  JMEWS 
input  processing  to  identify  subsequent  reports  as  “new”  patients  and  create  a  new  “people”  table  entry. 
The  result  was  that  a  patient  search  of  the  database  would  show  multiple  entries  for  the  same  name  and 
SSN  and  the  user  would  have  to  piece  the  history  together  by  reviewing  each  separate  entry. 

This  problem  was  due  to  errors  in  the  save  and  restore  function  at  JMedSAF.  JMedSAF  writes  periodic 
“save  files”  for  each  facility  to  disk  so  that,  should  a  system  failure  occur,  the  facility  patient  load  can  be 
restored  and  “freatmenf  ’  continued.  It  was  discovered  during  the  exercise  that  two  pieces  of  data  for 
patients  that  JMEWS  uses  to  link  patient  records  were  not  being  saved  in  the  files.  The  “admission  time” 
and  “date  of  birth”  items  are  used  as  one  of  many  “key”  fields  in  JMEWS  to  identify  patients.  Since  the 
data  for  these  fields  were  not  in  the  MTF  save  files,  when  a  failure  forced  the  reloading  of  these  files 
subsequent  reports  for  recovered  patients  did  not  have  the  correct  data  (zero  for  both  fields  -  patients  were 
2004  to  2006  years  old).  The  result  was  a  “new”  person  being  created  in  JMEWS. 

In  addition,  it  was  discovered  that  the  “admission  time”  information  was  not  included  in  the  JMedSAF 
evacuation  messages  (Trac2es  format  reports).  This  caused  JMEWS  to  create  “new”  people  for  each 
Trac2es  message  received. 

This  error  affected  only  inpatients  who  were  recovered  from  a  saved  file  and  patients  who  were  evacuated 
in  or  out  of  theater.  Outpatients  were  not  affected. 

The  “save  file”  errors  was  corrected  in  JMedSAF,  however,  implementation  of  the  new  software  was 
delayed  because  change  affected  the  reload  process  and  would  result  in  the  loss  of  all  current  patients.  The 
change  was  implemented  on  22  May  2006  when  it  was  deemed  that  the  loss  of  inpatient  status  would  no 
longer  pose  an  exercise  problem. 


Injury  Type  and  DNBI  Category 

JMedSAF  was  not  setting  the  injury  type  field  in  patient  messages.  This  resulted  in  the  inability  to  identify 
and  sum  WIA  patients  at  JMEWS/MSE.  This  was  corrected  on  19  May  2006. 

JMedSAF  attempted  to  output  the  DNBI  category  that  was  mapped  to  the  DEPMEDS  patient  condition. 
The  information  was  formatted  by  JMedSAF  as  a  list  code  rather  than  text  as  specified  in  the  JMEWS 
Interface  Control  Document  for  SAMS9  and  CHCSIIT.  Apparently  JMedSAF  was  using  the  wrong 
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JMEWS  DNBI  code  table  (“dnbi  category”  was  used)  and  this  resulted  in  the  JMEWS  display  of  erroneous 
category  information.  Fortunately,  the  MSE  program  performed  its  own  DNBI  mapping  based  on  ICD9 
information  and  the  erroneous  category  data  had  limited  distribution.  It  was  determined  that  easiest 
solution  was  to  modify  JMedSAF  to  not  submit  category  information.  Since  there  was  limited  use  of 
JMEWS  displays  at  the  CJTF,  it  was  decided  not  to  attempt  a  JMEWS  manual  correction  of  existing  data. 
The  JMedSAF  change  was  implemented  on  22  May  2006. 


4. 3  JMedSAF  Errors  Addressed  During  the  Exercise 

There  were  four  major  recompilations  of  the  JMedSAF  software  to  correct  numerous  issues  discovered 
during  the  exercise  period.  Updated  software  was  installed  on  5/16/06,  5/19/06,  5/20/06,  and  5/22/06.  All 
installations  occurred  only  on  the  tactical  scenario  systems.  The  system  providing  refugee  camp  simulation 
did  not  perform  any  “inpatienf’  processing  and  did  not  crash  during  the  exercise.  Therefore,  the  significant 
issues  were  not  encountered  on  this  system. 

The  following  is  a  list  of  the  JMedSAF  errors  identified  during  the  exercise  period.  These  errors  could 
have  been  found  with  more  pre-Ex  integration  testing. 


1)  Set  the  “on  hand”  to  equal  the  “stock  level”  value  in  the  MEDSITREP.  (Corrected) 

2)  If  a  facility  is  echelon  1,  set  the  number  refrigerators  to  zero.  (Corrected) 

3)  JMedSAF  needs  to  add  a  new  service,  “contractor”,  to  allow  certain  civilians  to  be  admitted  to  a 
military  MTF.  Using  service  “other”  works  for  now.  (This  problem  is  unresolved  at  this  time.) 

4)  JMedSAF  needs  the  correct  “duty  status”  to  be  set  for  a  contractor  and  identify  what  JMEWS 
wants  for  his  service.  (This  problem  is  unresolved  at  this  time.) 

5)  The  “vmtf  admif’  task  was  broken  in  the  patient  object  rewrite  and  needs  to  be  re -implemented. 
(This  problem  is  unresolved  at  this  time.) 

6)  JMedSAF  CHCS  Note  message  was  not  setting  the  treating  facility  correctly.  The  correction  was 
to  set  “computer  name”  to  the  MTF  name.  (Corrected) 

7)  Outpatients  entering  a  level  3  MTF  were  sending  a  CHCS  Admit  followed  by  a  CHCS  Discharge. 
A  SAMS9  Encounter  needs  to  be  sent  instead.  (Corrected) 

8)  The  “forced  evacuation”  function  caused  a  segmentation  fault  because  “evac  all”  was  setting  the 
pointer  to  the  patient  instead  of  the  pointer  to  the  queue  item.  (Corrected) 

9)  Date  of  Birth  data  wasn't  being  saved  so  when  a  patient  was  restored,  it  appeared  that  he  was  2006 
years  old.  (Corrected) 

10)  The  design  of  the  “forced  evacuation”  function  doesn’t  evacuate  from  several  queues.  It  should  at 
least  evacuate  the  patients  in  the  “evac  waiting”  queue.  (Corrected) 

1 1)  The  “dest  mtf  id”  was  erroneously  taken  out  of  the  “MTF  Notice”  interaction  and  needs  to  be  put 
back.  (Corrected) 

12)  Dropping  artillery  on  a  company  led  to  patient  objects  getting  lost  due  to  network  overload.  Since 
each  soldier  doesn't  know  about  the  other  ones  this  will  be  difficult  to  fix.  For  now  don't  drop 
artillery  on  companies,  use  platoons  instead.  (This  problem  is  unresolved  at  this  time.) 

13)  When  “forced  evacuation”  is  used,  need  to  send  CHCS  Discharges  for  the  evacuated  patients. 
(Corrected) 

14)  Admission  date  wasn't  being  saved  in  the  MTF  save  file.  (Corrected) 

1 5)  Sometimes  patients  appear  to  be  waiting  for  an  empty  ER.  This  may  be  a  display  only  issue  - 
more  investigation  is  needed.  (This  problem  is  unresolved  at  this  time.) 

1 6)  Make  sure  that  all  “vmtf_update_patienf  ’  calls  happen  before  the  patient  is  queued. 

17)  Save  scenario  saves  the  number  of  beds  at  the  time  of  the  save  since  this  is  parametric  data.  If  you 
subsequently  change  the  number  of  beds  the  original  numbers  will  come  back  when  a  scenario 
load  is  done.  This  information  should  be  kept  in  the  “saved  MTF”  file  as  well.  (This  problem  is 
unresolved  at  this  time.) 

18)  The  ZGl  field  in  SAMS9  report  was  nested  too  deep.  (Corrected) 

19)  The  ZGl.l  field  needs  to  be  added  to  SAMS9  reports.  This  specifies  the  injury  type.  (Corrected) 

20)  The  injury  type  also  needs  to  be  added  to  the  CHCS  Note  message.  (Corrected) 
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21)  The  “vmtf  admit  request”  process  needs  to  set  the  “battleinjury”  parameter  to  FALSE  if 
“autoevac”  is  true  so  that  patients  from  the  DNBI  generator  don't  get  battle  injuries.  (Corrected) 

22)  Some  JMedSAF  messages  were  not  being  parsed  by  the  JMEWS  FMS2  process  and  were  sent  to 
the  “unprocessed”  directory.  This  was  due  to  the  use  of  disallowed  characters  in  the  JMedSAF 
XML  output.  The  characters  “>”  or  “<”  in  the  PC  descriptions  files  were  changed  to  “&GT:”  and 
“&LT:”.  (Corrected) 

23)  When  reading  in  “pcSubjective”  the  process  was  using  VMTF  MAX  PCS  instead  of 
VMTF_MAX_PC_LENGTH.  (Corrected) 

24)  The  restore  code  needs  to  handle  blanks  in  the  nationality.  This  was  causing  segmentation  faults 
during  attempted  restarts.  (Corrected) 

25)  If  a  supply  or  staff  value  is  zero,  don't  send  it  to  JMEWS.  (Corrected  for  supplies  only.) 

26)  Don't  send  the  DNBI  category  (ZG  1.2)  to  JMEWS.  (Corrected) 

27)  Reissue  pickup  requests  doubles  the  number  awaiting  out  of  theater  evacuation  patients  on  the 
status  display.  (Corrected) 

28)  Add  VMTF  STATE  to  “cancel_all_requested_pickups”  parameters  -  vmtf  destroy,  pass  a  NULL 
for  this  parameter.  (Corrected) 

29)  Occasionally,  null  pointers  are  getting  onto  the  queues.  When  this  happens,  the  system  will  crash 
with  a  segmentation  fault.  (This  problem  is  unresolved  at  this  time.) 


5.0  Post  Exercise  Activity 

At  the  conclusion  of  the  CPX,  the  systems  were  required  to  be  scrubbed  for  security  reasons.  Prior  to  the 
disk  wipe  process,  information  needed  to  reconstruct  events  and  activity  was  identified  and  manually 
recorded.  The  disk  wipe  was  then  started  and  was  completed  by  the  following  day. 

An  After  Action  Review  (AAR)  for  the  medical  cell  had  been  scheduled  for  the  afternoon  of  25  May  2006. 
Due  to  scheduling  conflicts  for  some  of  the  participants,  the  AAR  was  postponed  until  a  later  date. 


6.0  JMedSAF  Performance  Evaluation 

JMedSAF  errors/issues  can  be  grouped  into  two  categories:  system  stability  and  quality  of  data  output  to 
JMEWS  IT 

System  Stability: 

While  the  camp  simulation  system  ran  basically  error  free  throughout  the  entire  exercise,  the  tactical 
simulation  experienced  a  number  of  failures.  The  basic  difference  is  that  the  camp  system  processed 
outpatients  only.  No  bed  queuing,  staff  queuing,  evacuations,  WIA  injections,  or  MSEL  injections  were 
done  on  the  camp  simulation  system.  All  of  these  processing  areas  produced  problems  in  the  tactical  forces 
simulation  systems. 

Data  Quality: 

As  noted  in  section  3.0  above,  there  were  several  issues  with  JMedSAF  message  data  content  uncovered 
during  the  exercise.  The  most  significant  of  these  was  the  loss  of  “key  field”  data  upon  file  recovery  which 
caused  JMEWS  II  to  create  erroneous  “new”  people  rather  than  linking  subsequent  reports  to  existing 
patients. 

The  majority  of  other  content  issues  were  due  to  the  lack  of  service  unique  identifiers.  An  example  of 
misunderstanding  of  JMEWS  II  database  parsing  was  discussed  above  in  the  DNBI  category  section. 

While  documentation  was  available  that  indicated  a  code  number  was  required,  there  was  no  indication  of 
what  the  valid  codes  were. 
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There  was  no  formal  doeumentation  available  for  the  faeility  messages  (MEDSITREP)  as  this  is  normally 
manually  generated  by  an  operator  on  the  TMIP  web  serviee.  The  JMEWS  II  team  provided  a  “Seenario 
Generation”  paekage  whieh  provided  automated  parsing  of  JMedSAF  faeility  messages.  Some  example 
XML  was  provided  for  the  development  effort,  but  there  was  little  in  the  way  of  guidelines  and  this  lead  to 
some  issues  with  JMedSAF  MEDSITREP  messages.  For  example,  the  simulation  uses  a  generie  staff  list 
to  map  diagnosis  to  required  treating  personnel.  In  previous  software  releases,  the  generie  staff 
requirement  was  mapped  to  a  table  of  serviee  speeifie  oeeupation  eodes  and  only  the  eode  was  passed  to 
the  medieal  database.  This  funetion  was  removed  from  the  software  beeause  the  MEDSITREP  examples 
available  during  development  listed  only  plain  language  oeeupation  titles  in  the  XML  and  therefore  the 
generie  list  was  used  instead.  This  proved  problematie  beeause  the  only  faeilities  showing  staff  levels  were 
US  Army  faeilities,  as  they  were  elosest  to  the  generie  list  eategories.  Leaving  aside  the  Thailand  and 
Singapore  faeility  eoneems,  it  is  possible  that  if  the  oeeupation  eode  output  had  been  retained,  JMedSAF 
output  would  have  been  of  better  quality. 

Without  a  more  detailed  knowledge  of  the  JMEWS  II  message  parsing  and  database  update  proeess,  the 
JMedSAF  team  eould  not  make  an  informed  deeision  regarding  best  praetiee.  For  example,  JMedSAF 
output  numbers  for  eaeh  staff  position  and  supply  eategory  even  if  the  appropriate  number  was  a  zero. 
During  the  exereise  preload  period,  it  was  noted  that  MSB  theater  summary  displays  often  indieated  a  red 
status  due  to  the  zeros  in  the  JMedSAF  input.  Apparently,  JMedSAF  should  not  have  ineluded  seetions  in 
the  XML  for  those  items  that  were  legitimately  zero.  While  there  were  no  errors  or  issues  with  JMEWS  II 
proeessing  of  the  data,  there  was  an  impaet  on  MSB  display  of  the  data. 


7.0  Conclusions 

All  of  the  system  and  interfaee  problems  noted  in  this  report  should  have  been  identified  and  eorreeted 
prior  to  the  exereise.  The  faet  that  they  were  not  is  due  primarily  to  the  laek  of  adequate  integration  testing. 

Prior  to  the  exereise,  the  only  time  that  all  systems  and  support  personnel  were  even  in  the  same  room  was 
at  the  end-to-end  test  in  mid  April.  The  end-to-end  test  objeetive  and  short  time  frame  did  not  lend  itself  to 
uneovering  anything  other  than  gross  problems.  Prior  to  the  end-to-end  test,  development  eollaboration 
and  testing  was  done  via  email  or  phone  eonversations.  The  JMedSAF  relianee  on  format  doeumentation 
without  praetieal  JMEWS  II  database  experienee  or  a  readily  available  subjeet  matter  expert  (SME) 
produeed  some  “best  guess”  ehoiees  and  limited  the  development  review  of  data  quality.  A  eomplete  run 
through,  before  the  exereise,  with  the  full  equipment  suite  and  with  all  eoneemed  personnel  in  one  loeation 
would  have  greatly  improved  performanee  and  data  quality. 
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